totally unrelated: When renaming flags, I've noticed that the way we are currently using flags in the e2e isn't great, as it isn't connected to the cli flags on a code level:

This is also a feature: if a flag changes, that's most likely a breaking change we want to catch! As a replacement for the just/bash/kubectl tests, it makes sense to pass flags independent of their definition in code.

But you're right that this is not what we want when we don't test user expectations, but do internal setup. Another facet of this is output: in the tests, I would sometimes prefer to get a go object instead of a file path (e.g. certs from verify, a manifest from generate, etc.).

What do you think about composing the runE of a command layer and a logic layer - like this (for a hypothetical implementation of ls -a):

func NewCmd() *cobra.Command {
	cmd := &cobra.Command{
		RunE: runE,
	}
	cmd.Flags().BoolP("all", "a", false, "list hidden files too")
	return cmd
}

type flags struct {
	all bool
}

func runE(cmd *cobra.Command, args []string) error {
	flags, _ := parseFlags(cmd)
	fileNames, _ := runInternal(flags)
	for _, fileName := range filenames {
		fmt.Fprintf(cmd.OutOrStdout(). "%s\n", fileName)
	}
}

func runInternal(f *flags) ([]string, error) {
	// run business logic
}

func parseFlags(cmd) (*flags, error) {
	// ...
}

And then we'd use the internal variant when we want the utility, but the command variant when we want to test externally observable behaviour.

This is also a feature: if a flag changes, that's most likely a breaking change we want to catch!

That's a good point.

Another facet of this is output: in the tests, I would sometimes prefer to get a go object instead of a file path (e.g. certs from verify, a manifest from generate, etc.).

I thought about that, too, and I use something like this in the sync server implementation. However, this introduces a hard restrictions on the output timing. In Constellation, we had/have situations where the timing of writing something to FS is of importance and cannot be done after the business logic is done, e.g., when the file should also be written in case of an error. It is difficult to keep the runE wrapper flat for complex programs.